fix(pi): emit parameters and execute in the generated pi adapter - #1678
Conversation
The generated Pi extension registered each MCP tool as { name, run }, but
Pi's ToolDefinition requires label, description, parameters, and execute.
Tools registered that way carried no parameter schema, so strict providers
such as xAI/Grok reject the request with a 422 'missing field parameters',
and the tools were uncallable because Pi invokes execute, never run.
Emit the full tool shape from the registry: label/description via new
accessors, the input_schema embedded directly as a JSON object literal, and
execute instead of run.
Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
The generated execute forwarded the raw MCP JSON directly, but pi's
ToolDefinition.execute must return { content: [{ type: 'text', text }],
details } — a result without a content array crashes the TUI's
getTextOutput on result.content.filter(...).
Request raw JSON from the CLI ('--json') so the bridge parses the MCP
result instead of the human-readable text, then wrap it: pass the content
array through, throw on transport errors, and stringify anything else.
Adds coverage asserting the corrected execute shape and the --json flag.
Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
clang-format wants no spaces inside a braced initializer. Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
|
We took this to the plausibility gate's end-to-end step before merging, and the probe against the current published Pi (@mariozechner/pi 0.70.6, fresh npm install) found the contract has moved under the PR — sharing the specifics because your three diagnosed breakages are real and the fix direction is right:
The mixed match suggests you validated against a different Pi build (understandable — 313 published versions). Could you tell us which version you ran the TUI against, and whether current Pi still loads TS tool extensions at all (vs. having moved on)? If extensions are alive in some form, we'd take a revision targeting the current AgentTool contract with the version noted in the generated header; if Pi has effectively dropped this surface, the honest fix may be retiring the adapter in favor of whatever Pi consumes now — which we'd also want to know. Thank you for the careful three-part diagnosis either way; it's the reason this got a real probe instead of a rubber stamp. |
|
The three breakages you listed were real on the coding-agent surface I was looking at. I ran against Small local context, since this is easy to miss from outside: I am in Vienna, same city as Mario / the Pi community here. Around three months ago (May 2026) it was going around locally that Mario Zechner joined Earendil GmbH and that Earendil took on pi.dev. That matches the packaging cut I can actually point at: 0.73.1 / 0.74.0 on 2026-05-07 (
Answers to the three points:
That finding is correct for The older coding-agent name on that scope is On 0.84.2, TS extensions are still a first-class surface:
So I would not retire the adapter. The install target for a re-probe should be
Yes. That was a real bug in this PR, and it is still true one wrapper up on 0.84.2 execute(
toolCallId: string,
params: Static<TParams>,
signal: AbortSignal | undefined,
onUpdate: AgentToolUpdateCallback<TDetails> | undefined,
ctx: ExtensionContext,
): Promise<AgentToolResult<TDetails>>
async execute(toolCallId, params, signal, _onUpdate, ctx) {
const result = await call(name, params, signal ?? ctx?.signal);
...
return { content, details: result ?? {} };
}and the generated header pins
Agreed. That half was already correct and is unchanged. A probe can be re-run against |
Pi 0.84.2 calls execute(toolCallId, params, signal, onUpdate, ctx). The generated (args, ctx) shape bound the call id as the MCP arguments. Forward params and signal, pin the @earendil-works/pi-coding-agent contract in the generated header, and lock the 5-arg form in tests. Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
DeusData
added
bug
|
Thank you for correcting the package target and updating the We will re-probe the generated adapter against the exact coding-agent version and extension contract you identified before making a merge decision. The process-spawn path is an existing adapter boundary rather than a new service dependency, but its argument order, cancellation signal, result normalization, and generated-string escaping all need end-to-end verification. Thank you for answering the version question with enough detail to make that probe reproducible. |
|
Thanks. Branch is synced with Re-probe target I used, so the next run is on the same surface:
String shape and path escaping are already in An in-tree fixture for arity + wrap is easy to add if that is cheaper than a TUI session. |
|
Taking you up on the fixture offer — that is the right answer, and better than the re-probe I promised. First, the correction deserves acknowledging properly rather than in passing. My plausibility probe ran against On the offer: yes, please add the in-tree fixture, and let us not do the live re-probe at all. I said I would re-verify argument order, cancellation signal and result normalization against a running Pi. Having thought about it, that is the wrong instrument for this repo. A check that depends on a third-party agent being installed and behaving is not something we can gate CI on, and a one-off manual probe expires the moment either side moves — which is precisely how we ended up here, with a contract assertion nobody could reproduce. A fixture that pins the emitted shape is reproducible, runs on every leg, and fails loudly when the contract drifts. Cheaper for you and worth more to us. Your existing assertions are already binding — ASSERT_NOT_NULL(strstr(js, "execute: async (toolCallId, params, signal, _onUpdate, ctx) => {"));
ASSERT_NULL(strstr(js, "run: (args, ctx)"));are red without the change. I also checked the flag you emit: What I would like the fixture to cover beyond that is the result wrapping — the One thing I want on the record, which is our problem rather than yours. The generated CI is 34/34 green and the branch is clean. Add the result-wrapping coverage and I will merge. |
Maintainer asked for in-tree coverage of {content, details} wrapping and
how tool errors are surfaced, plus a cheap abort-signal line. String-shape
only; no live Pi process.
Signed-off-by: Alex Musichen <alex.musichen@gmail.com>
|
Result-wrapping fixture is in |
|
Merged as I reported that Pi's contract had moved, having probed I checked the new assertions rather than counting them: the result wrap, the error throw, the The byte-identity gap I mentioned stays open and stays ours, not yours. Your fixture makes it smaller. |
Attacked the inputs rather than the patterns this time. Three worked.
ONE INVALID BYTE HID A WHOLE FILE. The scanner abandoned any file that
failed to decode as UTF-8, so appending a single 0xFF made it skip every
readable line in that file, plaintext payload included. A complete
evasion costing one byte. Files are now decoded with replacement rather
than abandoned, and a NUL byte -- git's own binary heuristic -- is what
marks a file as genuinely not a review surface. Only three tracked files
reach that path today: a PNG, a Windows ETW manifest and the nomic blob.
Better still, the evasion is now its own signal: a file with a TEXT
extension that is not valid UTF-8 is reported, because a stray byte in a
.md or .c is anomalous regardless of what surrounds it.
THE TRIPWIRE MATCHED CASE-SENSITIVELY. `Scripts/evil.sh` and
`.GitHub/workflows/` walked past it, and on a case-insensitive checkout
those are the same files as the guarded ones. Now matched with POSIX
character classes rather than `${v,,}` (bash 4 only) or `tr` (external),
so the logic can be tested on any shell -- which matters for a gate
nobody can run locally the way CI runs it.
THE FILES ENDPOINT CAPS AT 3000. A pull request padded past that limit
would hide a CI change in the tail, and the gate would report green over
a change set it never saw. It now compares what the API returned against
the count the PR itself declares and REFUSES when they disagree, rather
than passing on partial data.
All three are pinned in the selftest, alongside the requirement that a
PNG with invalid UTF-8 stays silent -- the hardening must not turn every
binary into a finding.
Verified end to end against real pull requests: #1422 refused (4 guarded
paths), #1245 refused (42 guarded, 392/392 received so no truncation),
#1778 refused (2 guarded), #1678 passes.
Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
2 participants
Problem
The generated Pi extension (
~/.pi/agent/extensions/cbmem.ts) registers each MCP tool as:Pi's
ToolDefinitionrequireslabel,description,parameters, andexecute. Therun-only shape is accepted by Pi's loader but produces tools that fail in two ways:parametersschema - strict providers such as xAI/Grok reject the request with422 missing field parameters(OpenAI and other providers tolerate the omission, so it only surfaces on some providers).execute- the tool is uncallable, because Pi invokesexecute, neverrun.Once
executewas wired up, a third problem surfaced:executeforwarded the raw MCP JSON (which has nocontentarray) instead of Pi's required result shape, crashing the TUI'sgetTextOutputonresult.content.filter(...).Fix
The adapter now emits the full tool shape from the registry:
Specifically:
cbm_mcp_tool_titleandcbm_mcp_tool_descriptionaccessors so the adapter reads metadata from the same registry that backstools/list, instead of drifting.input_schemais embedded directly as a JSON object literal (compact JSON is valid JavaScript), avoiding aJSON.parseindirection.callnow passes--jsonso the CLI emits the raw MCP result instead of human-readable text thatJSON.parsecannot parse.executereturns Pi's required{ content, details }shape: it passes the MCPcontentarray through, throws on transport errors, and stringifies anything else.Tests
client_adapter_pi_emits_parameters_and_executeassertingexecute/parametersare present, the legacyrun:shape is gone, the schema is embedded, and--jsonis requested.cbmem.tsloads and returns a valid result shape for success, error, null, and plain-object results.agent_clientssuite: 32/32 passing.